Thanks — the underlying questions are real (does the agent see quote context, and if the user replied to a message that mentioned the bot, should that count). But I can't recommend merging this in its current form. Two things, both verifiable from the code.

First, the quote injection into BodyForAgent duplicates context the agent already gets. dispatch.ts:468 already passes quotedContent as replyToBody to buildInboundPayload, and the SDK's buildInboundUserContextPrefix (reply-BwK-bN2w.js:1617-1626) unconditionally renders it as a "Replied message (untrusted, for context):" JSON block in the user-context prefix. After this PR the same text shows up twice in the prompt — once at the top of BodyForAgent as [Replying to: "..."], once as the SDK metadata block. The PR description says "SDK fallback paths prefer BodyForAgent over Body/ReplyToBody" — that's actually the BodyForAgent ?? CommandBody ?? RawBody ?? Body fallback chain, not a choice between BodyForAgent and ReplyToBody. The two render independently in the prompt, so this is duplication, not redundancy.

Second, quotedContentMentionsCurrentBot is broken on inspection. The candidate set is [account.config?.name, account.accountId, route.agentId] — the latter two are openclaw.json configuration keys (e.g. "default", "main"), they never appear in Feishu message text, so only account.config?.name can ever match. The three string patterns assume conflicting input formats: @${name} for plain-text-rendered mentions, >${name}< and ${name}</at> for the raw <at user_id="ou_xxx">Display</at> structure. quotedContent is one shape or the other, never both — so two of the three patterns are always misses. The function also has no tests; the added test file only covers buildBodyForAgent's quote injection.

For this to land, two changes:

1. Drop the BodyForAgent quote injection. If there's a real case where ReplyToBody isn't reaching the agent today, paste the trace into the PR description and we'll diagnose — but the fix shouldn't be a parallel injection that duplicates content for the normal case.
2. Rewrite mention detection to use structured data rather than string matching on rendered text. The Feishu API response from /open-apis/im/v1/messages/mget already returns a mentions array — the codebase already parses it via buildConvertContextFromItem in message-lookup.ts and uses the same pattern in parse.ts for inbound messages — and the bot's own open_id is available via LarkClient. Comparing IDs sidesteps display-name fragility entirely. Add a test covering both "bot mentioned in quote" and "bot not mentioned" cases.